《敏捷测试：以持续测试促进持续交付》读后感

【编者注：明天就是“世界读书日”，为此发表来自Happy-QA写的读书感（实际是两篇 https://www.zhihu.com/people/wgm-73，编者将其合二为一），鼓励大家多读书、多思考，让阅读成为一种生活方式，萃取书中精华为自己所用，快速成长、快乐工作】

测试以来，就一直关注敏捷测试相关的概念和实践方法，并一直关注着作者朱少民老师的公众号《软件质量报道》，考虑到公众号文章知识的零散性，因此购买了作者的书籍来系统的学习。

1. 什么是敏捷测试

敏捷测试是伴随着敏捷开发而来的，那么什么是敏捷测试呢？作者给的定义是 ：“敏捷测试”既不是一种测试方法，也不是一种测试方式，而是为了适应敏捷开发而特别设计的一套完整的软件测试解决方案。这个解决方案应该能够支持持续交付，涵盖所需的、正确的价值观、思维方式、测试流程、一系列优秀的测试实践和更合适的测试环境、自动化测试框架和工具。敏捷测试可以采用目前已有的各种测试方式、方法，包括手工探索式测试方式，接口自动化测试方式、UI自动化测试方式、边界值/等价类划分方法、组合测试方法等等。与传统测试相比，侧重点有所不同，主要的差别是在价值观、测试思维方式、流程和实践上。敏捷开发具有“敏捷宣言”，相应的作者也给出了“敏捷测试宣言”：

与开发协作测试 胜于 测试分工与测试工具

可运行的测试脚本 胜于 写在纸上的测试用例

从客户角度来理解测试需要 胜于 从已定义的需求来判定测试结果

基于上下文及时调整测试策略 胜于 遵守测试计划

对于第2点，我个人不太认同，我觉得“可运行的测试脚本” 和 “写在纸上的测试用例”同等重要，测试脚本的核心仍然是测试用例的设计，设计良好的测试用例、考虑周全的测试点有助于测试脚本的开发。这也是目前我们测试组重视测试用例的原因。对于第3点，目前来说测试组做得不太好，我们基本上都是基于定义的需求来判断测试结果，这也是有原因的，我们测试人员处于研发流程末端，对于ToB的医药行业来说，我们测试组目前缺乏相关的业务知识，测试结果的判定只能来自于需求文档。对于第4点，非常赞同，测试策略必定是基于上下文及时调整的。

该书里面还提到了一个我们经常遇到，开发测试都比较抵触事情：需求定义不清晰。比如我们最近几个迭代版本中，问卷模块 和 传统任务SaaS端的需求，这些需求我们经常听到大家调侃“以实际开发为准”。其实这是正常现象，这叫做“可协商”的需求，这类需求需要有产品，开发、测试协商解决，不断优化，最终适合客户的需求。所以以后我们再遇到类似的需求，不要抱怨产品同学，正确对待。

敏捷测试流程中，包括测试左移和测试右移。测试左移包括参与需求评审，参与研发的设计评审，即提前介入测试。测试右移包括，生产环境的测试：线上性能测试，线上安全测试，A/B测试，线上监控等等。目前我们测试组实践了测试左移，测试右移的思想。左移包括参与需求评审，查看开发的设计文档，提前介入测试；右移包括随时关注线上错误报警，定期测试生产环境。左移和右移还有更多的事情可做，以后会随着需要加强。

敏捷测试不能缺少手工测试和自动化测试。在新的迭代版本中，手工探索式测试效率高；而对于回归测试用，自动化测试是最优的选择。即测试 = 检测 + 试验，检测已知的，试验未知的; 也即测试=基于脚本的自动化检测 + 基于人工的探索式测试

2. 如何测试才更敏捷

～需要敏捷测试的思维方式～

1）成长性思维

测试人员需要具备成长性思维，相信我们自身的能力是可以通过培养不断成长的；面对挑战是拥抱而不是躲避；面对失败不是责备自己、同事，而是需要搞清楚为什么失败以及如何避免再次失败；要内心充满力量、充满自信。

可参考：读了这篇文章，受益终身：敏捷测试思维模式

2）团队对质量负责的思维

测试守护质量，提供质量信息，甚至帮助团队改善质量，自然是很有价值的，但是如果依赖测试来保证质量，那么其实是很难保证质量的，而且成本很高。应该让整个团队关注质量，从需求开始尽可能一次把事情做对，从而构建出高质量的产品，这对企业来讲更有价值——效率更高，成本更低。

可参考：什么是软件质量管理的底层逻辑？

3）上下文驱动的思维

上下文驱动的思维是要认识到上下文是一直在变的，测试的策略和方法也要更具上下文及时调整、不断优化，尽可能达到更有效、更高效的测试状态。上下文可以简单地理解为项目所处的环境，以及所要满足的条件等，包括项目人员、风险变化、研发状态、质量标准等。

可参考：上下文驱动的自动化测试方法（三）

4）用户思维

用户思维的意思是要做对客户有价值的事情。

可参考：用户真正想要什么？

～需要构建强大的敏捷测试基础设施～

测试基础设施是支持测试运行、测试开发、测试管理，以及与研发环境集成的综合性平台。敏捷的目标就是要做到持续交付，尽快向用户交付满足需要的、有价值的软件，那么敏捷测试就离不开稳定、高效、准确的基础设施，以满足对于持续交付的需要。而要做到持续交付，需要做到持续运维、持续部署、持续测试、测试集成、测试构建。

• 持续构建，包括代码的编译、测试、打包等活动

• 持续集成，关注的是让代码能够工作在一起，以便开展进一步的测试。

• 持续测试，不等于自动化测试，一次迭代中的新功能特性的测试采用手工（探索式）测试更高效，回归测试尽量用自动化的方式持续验证新的代码和功能。

• 持续部署，就是按需部署，通过技术手段随时随地、快速地将软件包部署到各类环境（包括测试环境、准生产环境、生产环境）中，并确保系统可以正常工作。

• 持续运维，要实现全自动的监控、告警、故障定位和自愈，以及自动的数据收集、分析和处理。

• 持续交付，是一种能力，也就是说，能够以可持续方式，安全、快速地把代码变更部署到生产环境，让用户使用。

～需要测试左移～

测试左移是指让测试尽早开始，把测试活动左移到需求分析阶段，目的是及时发现研发前期的错误，避免将错误带到后面的研发活动中。测试左移通过持续地对产品需求和设计进行评审，及时发现需求定义和设计中的问题，加强单元测试、持续集成等。

～需要测试右移～

测试右移是指在生产环境中对软件进行测试，即把测试活动延伸到了运维阶段，包括在线性能测试，在线监控告警，安全性监控等。

3. 敏捷测试的主要风险

• 需求不清晰（可协商的需求）

• 需求频繁变更

• 时间太紧张

• 自动化测试的有效性

其实这些风险并不是敏捷测试特有的，只要是软件测试都会遇到这些问题，测试人员要做的是在测试过程中遇到这些风险应该如何应对。测试人员要有能力识别和控制这些风险，可以建立风险项目检查表以及相应措施，示例如下：

类别	内容及潜在影响	控制措施
需求风险	需求不清晰、频繁变更导致测试计划、工作量等发生变化	和产品人员充分沟通，深度参与需求评审
自动化测试	自动化测试覆盖率、有效性等	对测试自动化进行合理的分层测试，提高单元测试和接口测试的覆盖率
人员风险	测试人员的状态、责任感等	加强团队人员建设
环境风险	测试环境是一个模拟环境，很难和实际运行环境一致	测试右移，生产环境持续测试
测试范围（广度）	很难完成100%的测试覆盖率，有些异常case及细节容易被忽视	在有条件的情况下，采用交叉测试

4. 传统测试与敏捷测试的区别

传统测试更强调测试的独立性，将“开发人员”角色和“测试人员”角色分得比较清楚。而敏捷测试可以有专职的测试人员，或者少量的测试人员，也可以是“全民”测试，即在敏捷测试中，可以没有“测试人员”角色，强调整个团队对测试负责。

传统测试具有明显的阶段性，从需求评审、审计评审、单元测试、集成测试、到系统测试等，从测试计划、测试设计、测试执行、测试报告，逐个阶段往前推进， 而敏捷测绘更强调更早测试、持续测试、持续的质量反馈（就算软件上线，测试活动也没有结束），没有明确的阶段界限。

传统测试强调测试的计划性，而敏捷测试更强调测试的速度和适应性，侧重不断地调整计划以适应需求的变化。

传统测试强调测试测试是由“验证”和“确认”两种活动构成，而敏捷测试没有这种区分，始终以用户需求为中心，每时每刻不离用户需求，将验证和确认统一起来。

传统测试关注测试文档，包括测试计划、测试用例、缺陷报告、和测试报告等，而敏捷测试更关注产品本身，关注可以交付的客户价值。在敏捷测试中，强调面对面的沟通、协作，强调持续的质量反馈、缺陷预防。

传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响，但敏捷测试的基础就是自动化测试，敏捷测试是由良好的自动化测试框架支撑的快速测试。